1. Field of the Invention
This invention relates to the field of improved execution environments for software applications running in the JAVA(™) language. In particular, the invention relates to improvements designed to support the operation of multiple unmodified JAVA(™) applications on an unmodified JAVA(™) Virtual Machine.
2. Description of the Related Art
1. Description of Problem
JAVA(™) applications are transportable byte codes that can be executed on a number of platforms. The execution environment for JAVA(™) applications is a JAVA(™) Virtual Machine (JVM). For each platform a JVM must be available to execute the JAVA(™) applications. The specification of, and the implementation of, a JVM is described in documents such as “JAVA(™) Virtual Machine”, John Meyer and Troy Downing, O'Reilly and Associates, 1997. Additionally, the book “The JAVA(™) Virtual Machine Specification”, Tim Lindholm and Frank Yellin, Addison Wesley, 1997, also describes a JVM.
For each JAVA(™) application that a user wishes to run on a JAVA(™) Virtual Machine, a separate JVM must be run together with a separate execution environment. This execution environment includes an object store in memory, also referred to as a JAVA(™) heap, for storing JAVA(™) objects and data. Also, the environment includes a “garbage collector” that deletes unused objects and compacts the JAVA(™) heap. This arrangement consumes large amounts of system memory or each JVM, and thus each application. When used, as JAVA(™) was originally designed on a client computer, this is riot a problem as a user is typically running only one or two applications at a time. Further, the user's computer is dedicated to running those applications.
In contrast, server computers may require that multiple JAVA(™) applications be running simultaneously. For example, a server might be deployed to handle processing for a large number of client computers. If the JAVA(™) standard is followed, each of running JAVA(™) application on the server would need to run in separate JVM's, each with an associated execution environment. Thus, each application would have its own JAVA(™) heap and separate garbage collection process. The multiplicity of the garbage collection processes across all of the JVM's can consume significant amounts of processor time and lead to decreased performance.
The JAVA(™) Virtual Machine could be rewritten in its entirety to support multiple applications at one time. However, such an approach would require major re-architecting of the JAVA(™) and/or JVM standards and specifications. Additionally, JAVA(™) applications could be rewritten in source code to support multiple applications on a single JVM.
2. Prior Art JAVA(™) Execution Environment
Turning to FIG. 1, and the prior art JAVA(™) execution environment, the execution environment includes a JAVA(™) Virtual Machine 100, including JAVA(™) base classes 102 and a primordial class loader 104. An optional application class loader 106 is depicted as well as a single JAVA(™) application 108. This is the typical JAVA(™) execution environment according to the prior art.
In the normal operation of a JVM, a JAVA(™) application compiled to run on the JVM arrives in a sequence of byte codes arranged in class files. The class files, which can be remotely or locally accessed, are loaded by class loaders and executed in a threaded environment by the JVM. Execution of JAVA(™) applications take place in threads, which are part of thread groups, and invokes calls to methods of the associated objects. Each thread that is created from a thread in a given thread group also belongs to that thread group. Executions of thread causes the creation of objects, which are stored in portions of the JAVA(™) heap during run time. An application is able to run on a JAVA(™) execution environment with a large set of JAVA(™) base classes, which are sometimes considered part of the JVM. The base classes received calls from the application to enable many basic functions.
Object creation during execution within the JVM utilizes a class loader architecture. There are two types of class loaders in the JAVA(™) execution environment. The first type is a “primordial” class loader, e.g. the primordial class loader 104. The primordial class loader is considered part of the JVM itself and is designed to load certain class loaders. Usually the primordial class loader 104 is used to load classes of the application.
Another type of class loader is available for loading objects. This type of class loader is a JAVA(™) class loader object written in JAVA(™). This type of class loader can be installed by a JAVA(™) application into a thread. When this type of class loader is installed into a thread other application objects within that thread are loaded using that class loader.
Notably the prior art JVM does not allow for a hierarchy of application class loaders. Thus, a JAVA(™) application such as the JAVA(™) application 108 cannot install additional application class loaders.
3. Conclusion
The prior techniques do not permit the execution of multiple unmodified JAVA(™) applications on a single unmodified JAVA(™) Virtual Machine. Further, the prior techniques do not support shared usage of the JAVA(™) base classes by applications running on the JVM. Accordingly, what is needed is a method and apparatus for supporting multiple unmodified JAVA(™) applications on a single JVM using a single copy of the base classes for all of the JAVA(™) applications.